In software engineering, an entity model, or entity-relationship model, refers to a particular type of data model that describes and defines a process in a problem domain. This process is modeled as components (entities) that are linked with each other by relationships that specify dependencies and requirements between them.
An entity model can be created by a data modeler using software tools. The entity model thus created can be translated into a physical database design and mapped to physical storage devices by a database administrator (DBA). For example, in the case of a relational database management system which stores data in tables, every row of each table represents one instance of an entity. Some data fields in the tables point to indexes in other tables. Such pointers represent the relationships.
As is known, a database management system is a complex software program that provides users with a systematic way to create, retrieve, update, and manage data. There are a number of problems with an existing approach to entity modeling in an application development environment that relies on data modelers (e.g., the IT staff) knowing how to interact with database management systems, essentially requiring them to have data administration and entity modeling expertise. However, the skills required for entity modeling are different from the skills required for data administration. As such, a data modeler may spend time working on what functionality to add to an entity as well as on figuring out how to correctly and appropriately add that functionality to an entity.
Some existing approaches to entity modeling involve using different software tools. Since the entities and their relationships are stored in a database, these software tools must provide a way to access them in the database. To do so, code for different user interfaces need to be written and implemented and data modelers need to learn how to use these software tools. Moreover, functions provided by one entity modeling tool may not be reusable or extensible by another entity modeling tool.
One example of an entity modeling system has at least one processor, a data store storing a plurality of entity building blocks, at least one non-transitory computer readable medium, and stored instructions embodied on the at least one non-transitory computer readable medium. The plurality of entity building blocks may be created separately and independent of any particular entity to be modeled in a process solution (which refers to a particular application that is custom developed/built for a problem domain).
One problem that application developers face is that they frequently need to let their customers customize their applications, while still being able to release updates to the applications. In typical scenarios, this requires the customers to go through the customization process with each new application release.
Another problem in the art relates to polymorphic relationships between entities. For example, an insurance company may have different types of insurance policies, all of which go through a standard claims process. When processing claims, it may be desirable to process all types of claims, without necessarily being concerned about the type of policy.
Another problem in the art relates to how users can effectively use components (e.g., applications, etc.) from third party applications, i.e., applications for which only binaries are available. Enabling a document type to be used as a run-time reference is a challenge, as it may require the introduction of a special class in the modeler's class definition. It can be counterintuitive for a modeler developer to take in to consideration design-time versus run-time availability of various concepts, while being in the phase of domain modeling. In addition, run-time usage of an application component is different from its design-time usage. In other words, some properties of a document are required when used during application development, but are not relevant after the document is deployed. Introduction of run-time reference document types would require thorough insight in the domain and future usage of the included concepts.
It would sometimes desirable to build applications by reusing, extending, or customizing functionality offered by other applications or application components. More specifically, it would be desirable to enable entity-based applications to be reused, extended, and/or customized in an enterprise environment.
In view of the foregoing, there is a need for innovations and improvements to entity modeling in enterprise computing environments.